Blockchain-based identity and transaction platform

ABSTRACT

Systems, methods, and computer media implementing blockchain-based identity and transaction platforms are described herein. Identity information, such as a photo, for a person can be encrypted and stored in a blockchain as part of enrolling the person as a user in a blockchain-based identity and transaction platform. Trust relationships can be formed between the user and other users, and records of the trust relationships can also be stored in the blockchain. Transactions between the user and other users with whom the user has formed a trust relationship can also be stored in the blockchain. The transactions can be authorized, for example, through a multi-stage verification process that accesses information stored on the blockchain. The transactions and identity information, along with other information, contribute to an economic identity of the person.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No.62/495,574, filed on Oct. 17, 2015, and titled “UNIVERSAL IDENTITY ANDPERSONAL DATA STORAGE, UPDATE AND RETRIEVAL IN THE BLOCKCHAIN. THISINCLUDES PERSONAL DEMOGRAPHIC INFORMATION, CREDIT HISTORY ANDTRANSACTIONS, CONTACTS AND RELATED RELATIONSHIPS, PROPERTY AND ASSETRIGHTS, GENERAL PREFERENCES AND GEO-LOCATION. ALL STORED IN THEBLOCKCHAIN,” which is incorporated herein by reference in its entirety.

BACKGROUND

In today's modern economy, individuals typically establish accounts withdifferent institutions and entities and use these accounts to interactwith others to obtain goods and services and establish histories.Accounts are typically maintained on server computers under the controlof the institution or entity. Such accounts, however, are oftenvulnerable to security risks such as hacking and identity theft and arefrequently out-of-date or inconsistent. Such accounts are alsotraditionally less accessible to individuals in developing countries orrefugee areas.

SUMMARY

Examples described herein relate to blockchain-based identity andtransaction platforms. In an example approach, identity information(e.g., a photo) for a person can be encrypted and stored in a blockchainas part of enrolling the person as a user in a blockchain-based identityand transaction platform. Trust relationships can be formed between theuser and other users, and records of the trust relationships can bestored in the blockchain. Transactions between the user and other userswith whom the user has formed a trust relationship can be authorized.Records of the transactions can also be stored in the blockchain.Authorization can involve, for example, a multi-stage verificationprocess that accesses information stored on the blockchain. Thetransactions and identity information, along with other information, cancontribute to an economic identity of the person. Storing an economicidentity (and the underlying information that forms the economicidentity of the person) in the blockchain results in a secure platformaccessible to people regardless of their economic or geographiccircumstances.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

The foregoing and other objects, features, and advantages of theinvention will become more apparent from the following detaileddescription, which proceeds with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example environment in which ablockchain-based identity and transaction platform can be implemented.

FIG. 2 illustrates an example economic identity.

FIG. 3 is a diagram illustrating an example method of authorizingtransactions in a blockchain-based identity and transaction platform.

FIG. 4 is a diagram illustrating an example method of enrolling a personas a user in a blockchain-based identity and transaction platform.

FIG. 5 is a diagram illustrating an example method of authorizingtransactions in a blockchain-based identity and transaction platformusing a multi-stage verification process.

FIG. 6 illustrates interactions in an example transaction authorization.

FIG. 7 illustrates interactions in an example transaction authorizationin which a second code is sent to a user's mobile device.

FIGS. 8-23 illustrate example user interfaces for interacting with ablockchain-based identity and transaction platform.

FIG. 24 is a diagram of an example computing system in which somedescribed embodiments can be implemented.

FIG. 25 is an example mobile device that can be used in conjunction withthe technologies described herein.

FIG. 26 is an example cloud-supported environment that can be used inconjunction with the technologies described herein.

FIG. 27 is a diagram of example personas based on a secured,blockchain-based economic identity.

DETAILED DESCRIPTION

Using the systems, methods, and computer-readable media describedherein, a blockchain-based identity and transaction platform can beimplemented. People can enroll as users in the platform using identityinformation such as an image or photo (e.g., of the person's face). Oncea user profile has been established, the user can form trustrelationships with other users of the platform and perform transactions.Transactions can include, for example, funds transfers, medicaltreatment authorization, food assistance authorization, and othertransactions. The identity information, trust relationships,transactions, and other information are stored in blocks in ablockchain. Unlike conventional approaches in which a user's informationis stored and maintained on centralized server computers managed by manydifferent entities and stored behind entity-specific firewalls, each ofwhich may be vulnerable to security threats, the blockchain-basedidentity and transaction platform examples described herein providesecure storage of an individual's information through a distributednetwork of computers.

The example blockchain-based identity and transaction platforms alsoallow a person to integrate various types of information to create aneconomic identity that can be used to access goods and services. Theeconomic identity can include, for example, a person's history ofincome, employment, payments to creditors or other parties, etc. Theeconomic identity can be used to establish the qualifications andbackground that allow the person to participate in a credit-based (orotherwise sophisticated) economy. As an example, individuals indeveloping countries or refugee areas may not have access toinstitutions and entities necessary to build a history (e.g., a creditscore) that allows the individual to access credit that can be used tostart a business, purchase necessary farming equipment, make capitalimprovements, etc. An economic identity established through ablockchain-based identity and transaction platform can provide evidenceof a person's creditworthiness, identity, legal status, etc. thatenables the person to obtain credit. Because of the distributed natureof a blockchain, such an economic identity is both portable andaccessible regardless of the economic or geopolitical situation in auser's current location. In addition to providing those in the developedworld with a secure, integrated platform, the examples described hereinhave the potential to drastically reduce poverty in developing countriesand help millions of refugees establish themselves in the world economyby providing access to credit. Examples are described below withreference to FIGS. 1-27.

FIG. 1 illustrates an example environment 100 in which ablockchain-based identity and transaction platform can be implemented.As used herein, “blockchain” refers to a distributed storage platformand network in which individual “blocks” are connected in a chain. Eachblock is linked to the previous block in the blockchain by, for example,including a hash of the previous block as a “proof of work.” Varioushash functions, including functions in the Secure Hash Algorithm (SHA)-1or -2 families, such as SHA-256, can be used to perform a one-way hash.For a one-way hash, it is generally considered to be impossible orimpractical to generate the input (the “message”) to the hash functionbased on the output (the “message digest” or “digest”) of the hashfunction.

In a blockchain, the individual blocks can store a variety of data thatmay or may not be related (e.g., may or may not be associated with asame user). In environment 100, mobile computing devices 102 and 104 arein communication with computing device(s) 106 over a network 108.Network 108 can be the Internet, a Local Area Network (LAN), a WirelessLocal Area Network (WLAN), a Wide Area Network (WAN), or other type ofnetwork, wired or wireless. Computing device(s) 106 can be, for example,one or more server computers. Computing device(s) 106 includesprocessor(s) 110, local storage 112, and memory 114. Environment 100 canalso include one or more additional computing devices, such as desktopcomputers, (not shown) in communication with computing devices(s) 106over network 108.

Computing device(s) 106 also includes an enrollment engine 116 and atransaction engine 118. Enrollment engine 116 is configured to enroll,by processor(s) 110, a person as a user in the blockchain-based economicidentity and transaction platform based on identity information for theperson. As an example, a person can use mobile computing device 102 (orother computing device, such as a desktop computer) to enter a name,government-assigned identification number, etc. and/or to take an image(e.g., a “selfie”) of themselves and, using a web application or usingclient-side software installed on mobile computing device 102, uploadthe image and/or other information to computing device(s) 106 as theidentity information. Example software user interfaces are illustratedin FIGS. 8-23. Enrollment engine 116 is configured to create a uniqueidentifier for the person based on the uploaded identity information.The identity information can be encrypted, either by computing device(s)106 or through an encryption service 120. Encryption services arediscussed in more detail below. The encrypted identity information canthen be stored in a blockchain 122. Blockchain 122 is implemented on agroup of distributed computing devices 124 that are accessible vianetwork 108. Additional enrollment examples are discussed in detailbelow with respect, e.g., to FIG. 4.

Transaction engine 118 is configured to authorize, by processor(s) 110,transactions between users who are in a trust relationship. Trustrelationships can be established, for example, by request or invitationof a user and an acceptance by another user. Transactions can beauthorized, at least in part, through interaction with a verificationagent computing device 126. Verification agent computing device 126communicates with computing device(s) 106 through network 108. As anexample, a first user can initiate a funds transfer to a second userthrough a web application or through client-side software. Transactionengine 118 can be configured to perform a verification of the fundstransfer using, for example, a multi-stage verification approach thataccesses information stored in blockchain 122. Transaction verificationexamples are discussed in detail below with respect, e.g., to FIGS. 5,6, and 7.

Identity information, transaction information, and other information fora user that is stored in blockchain 122 can form an economic identity ofthe user. FIG. 2 illustrates an example economic identity 200. Economicidentity 200 includes identity information 202, linked accounts 204,employment history 206, utility information 208, education history 210,aid record 212, property ownership 214, medical history 216, andtransaction history 218. Although economic identity 200 is shown asincluding each of the preceding particular categories of information,example economic identities can also include only some of thesecategories of information and/or include additional categories ofinformation. Identity information 202 can include, for example, an imageof a user, a name, government identifier(s), and/or fingerprint or eyepattern information of the user (or other biometric information of theuser). Linked accounts 204 can include, for example, banking,investment, or credit accounts associated with the user. Employmenthistory 206 can include employer names and/or addresses, job titles,dates of employment, salaries, and/or other employment information.

Utility information 208 can include utility accounts for the user,records of past payments, and/or other information. Education history210 can include degrees earned, educational levels completed, coursescompleted, certifications obtained, test scores, etc. Aid record 212 caninclude food assistance (e.g., food packets distributed by a UnitedNations or other aid entity) or loans received, loans repaid, etc.Property ownership 214 can include property deed information, propertylocation information, property transaction information, etc. Medicalhistory 216 can include medical records, medical insurance information,medical aid information (e.g., vaccinations received), etc. Transactionhistory 218 can include funds transfers received or provided, aid ormedical assistance authorizations (even if also included in aid record212 or medical history 216), or other transaction information. Theinformation included in identity information 202, linked accounts 204,employment history 206, utility information 208, education history 210,aid record 212, property ownership 214, medical history 216, andtransaction history 218 can be presented as aggregated information or asindividual items.

Economic identity 200 can also include a “trust” score similar to acredit score that indicates a level of creditworthiness orresponsibility that can be used by businesses or institutions who areusers in the blockchain-based identity and transaction platform. Thetrust score can be determined based on a weighting scheme (e.g.,quantification of employment history weighted at 50%, quantification oftransaction history weighted at 30%, quantification of education historyweighted at 20%, etc.). In some examples, particular businesses orinstitutions are able to select particular criteria of interest and/ordesired weightings for different criteria, and a custom trust score isdetermined based on those criteria. Various approaches to quantifying aparticular category can be used (e.g., percentile rank of criteria,scale of 1-10, etc.).

Economic identity 200 is stored in blockchain 220. Blocks 222, 224, 226,and 228 of blockchain 220 are shown in FIG. 2, but any number of blockscan form blockchain 220. As indicated by the arrows between blocks 222,224, 226, and 228, the respective blocks are linked to the previousblock in the blockchain. This link can be in the form of, for example, ahash of the previous block.

FIG. 3 illustrates a method 300 of authorizing transactions in ablockchain-based identity and transaction platform. In process block302, identity information for a person is encrypted, and the encryptedidentity information is stored in a blockchain as part of enrolling theuser in the blockchain-based economic identity and transaction platform.The identity information can include, for example, an image of theperson. The identity information can alternatively or additionallyinclude at least one of a name, government identifier(s), fingerprint,or eye pattern information.

In process block 304, records of trust relationships between the userand other users are stored in the blockchain. For users of theblockchain-based identity and transaction platform, a trust relationshipcan be formed, e.g., by performing a search or lookup of registeredusers and sending a user identified through the search or lookup amessage indicating that a trust relationship is desired. If the otheruser accepts the request, then a trust relationship is established. Insome situations, however, a user may wish to transfer funds or performanother transaction with a person who is not a user of theblockchain-based identity and transaction platform. In such situations,a user may send an invitation to connect to the person's email address,messaging account, or other contact point, with the message including alink or instructions for creating an account with the platform andindicating that the user would like to establish a trusted relationship.

Transactions between the user and one or more of the other users withwhom the user has formed a trust relationship are authorized in processblock 306. The transactions are stored in the blockchain. Records of thetransactions are stored in the blockchain in process block 308. At leastsome of the transactions and identity information contribute to theeconomic identity of the person. The economic identity can also includeat least one of employment history information, education historyinformation, land ownership information, or medical history informationfor the user. Additional information that can be part of the economicidentity is illustrated, e.g., in FIG. 2.

In process block 306, the identity information of a user can be used inthe authorization. For example, when the identity information includesan image of the person, this image can be used in authorizing thetransactions. Process block 306 can include a multi-stage verificationapproach as discussed, for example, with respect to FIGS. 5 and 6. Insome examples, method 300 further comprises providing the economicidentity of the user to a requesting party, where the requesting partyis a user in the blockchain-based economic identity and transactionplatform. As an example, a user may wish to establish a line of credit,purchase equipment, or perform another transaction, and prior toinitiating or authorizing the transaction, the requesting party canrequest the user's economic identity (e.g., through a client-sidesoftware application) in order to evaluate the user as a potentialdebtor, purchaser, employee, etc.

In some examples, businesses and institutions that establish accountswith the blockchain-based economic identity and transaction platform canaccess (e.g., through a web application or client-side software) a userinterface to allow the business or institution to view economicidentities for other users who give permission. In some examples, userscan control which categories of information are included in theireconomic identity and/or can authorize read access of only certaincategories in response to a request. For example, if a user isinterested in taking out a loan from an entity, and the entity requeststhe user's economic identity, the user may choose not to share medicalhistory information or other information that may not be relevant to theentity.

FIG. 4 illustrates a method 400 of enrolling a person as a user in ablockchain-based identity and transaction platform. In process block402, identity information for a person is received. Identity informationcan include an image of the person (e.g., a selfie) and/or a name,government identifier(s), fingerprint, or eye pattern information. Inprocess block 404, the identity information is encrypted. Variousencryption techniques can be used. In process block 406, the encryptedidentity information is stored in a block of a blockchain. In someexamples, a single encryption key can be used and can be stored as, forexample, an environmental variable on a computer storage deviceassociated with the blockchain-based identity and transaction platform.

In some examples, an encryption service, such as encryption service 120of FIG. 1, can be used. The encryption service can create and manageencryption keys. In such an example, software implementing aspects ofthe blockchain-based identity and transaction platform can make a callto the encryption service to encrypt the identity information receivedin process block 402. The service creates the keys, retains a privatekey, and provides both a public key and the encrypted identityinformation to the software that made the call to the service. Theencryption service can be a web service.

In process block 408, a unique identifier associated with the person isestablished based on the encrypted identity information. In someexamples, process block 408 includes designating the encrypted identityinformation as the unique identifier. Other unique identifiers can alsobe used. In some examples, various actions may be taken to validate orauthenticate a user's identity prior to establishing the uniqueidentifier. As an example, various third-party sources of informationcan be used to verify the user's identity.

Method 400 can also further comprise associating, with the uniqueidentifier, at least one of medical, employment, educational, propertyownership, or economic information (e.g., linked accounts, transactionhistory, etc.) corresponding to the person and storing the medical,employment, educational, property ownership, or economic information inthe blockchain. Some or all of the associated information can be used toform the economic identity of the person, as discussed, for example,above with respect to FIG. 2. Transaction information representing oneor more transactions between the person and one or more additionalparties, as well as trust relationships between the person andadditional parties, can also be stored in the blockchain in associationwith the unique identifier or other information indicating the user(such as the public key, even if the public key is not used as theunique identifier).

FIG. 5 illustrates a method 500 of verifying a transaction in ablockchain-based identity and transaction platform. In process block502, a recipient for a transaction is identified. A recipient is, forexample, the person or user who will receive a funds transfer, receivemedical assistance, receive food assistance, etc. In some examples, arecipient can be any person, and in some examples, the recipient islimited to a user of the blockchain-based identity and transactionplatform. In some examples in which the recipient is not a user of theplatform, the person can be sent a link or instructions for enrolling asa user in the platform after the transaction is initiated, and thetransaction does not proceed until the person enrolls and establishes atrust relationship with the sender. In such examples, the recipient is aprospective recipient until the person enrolls and establishes the trustrelationship.

First stage authentication data is generated in process block 504. Firststage authentication data can be, for example, a code including numbersand/or letters. The first stage authentication data can be provided tothe recipient and can serve as an indication to the recipient that abenefit is available to be claimed. For example, the recipient canreceive a text message, email message, or application alert including: astatement that a benefit is available to be claimed; a code (e.g., a9-digit numeric, alphanumeric, or letter code); and instructions tocomplete the verification process in order to claim the benefit. In someexamples, the first stage authentication data is only valid for acertain amount of time (one hour, one day, one week, etc.). In someexamples, the first stage authentication data is valid long enough toallow for the recipient to claim the benefit according to therecipient's schedule (e.g., until after a work shift, trip, or otherevent is completed).

In process block 506, an indication is received that the first stageauthentication data has been provided to a verification agent. Averification agent is a user in the blockchain-based identity andtransaction platform who serves in a third-party role. The verificationagent can communicate with the platform through, for example,verification agent computing device 126 of FIG. 1. As an example, in arefugee context, the verification agent can be a member of a UnitedNations or other entity that is an assistance provider, and when arefugee receives (e.g., via a text on the refugee's mobile phone) amessage and code indicating that a food assistance packet is available,the refugee takes the code to the verification agent, who can be locatedat a kiosk, building, or other facility. The verification agent thenenters the code through a software application user interface.“Verification agent” as used herein may also refer to a verificationagent computing device. In some examples, the person can enter a codeinto an automated terminal.

In process block 508, the first stage authentication data is verified.For example, the code provided in the initial message can be comparedagainst the code entered by the agent (or in some examples, entered bythe person). Verification of the first stage authentication dataprovides some confirmation that the person who provided the code to theagent is the actual recipient.

In process block 510, identity information for the recipient isretrieved from one or more blocks in a blockchain after verifying thefirst stage authentication data and is transmitted (e.g., to theverification agent). The identity information can be used to furtherconfirm that the person is the actual recipient. Continuing the refugeeexample above, after the verification agent has entered the codeprovided by the person, and the code has been verified (e.g., by aremote server computer) as a match to the code provided in the originalmessage, an image of the recipient can be provided to the agent. Theimage can be the image used to create the recipient's profile (and theimage that is encrypted and stored in the blockchain). If the imageappears to be the same person as the person in the presence of the agentwho provided the code, then the agent confirms an identity match.

In some examples, facial recognition software is used to determinewhether there is a match between the person and the image. In someexamples, fingerprint or eye pattern matching can be performed insteadof comparing the appearance of the person to an image. In examples inwhich an automated terminal is used, instructions can be presented forthe person to place their finger, eye, or face on a scanner or in frontof a camera, and comparison of the identity information can be performedby software.

In some examples, rather than affirmatively confirming an identitymatch, the agent can refuse to complete any further actions (e.g.,entering a second code) if the person in the agent's presence does notappear to match the image (or other biometric information).

Identity information, such as an image, is stored in an encrypted formin the blockchain. In examples in which an encryption service is used,software associated with the platform can make a call to the encryptionservice and request a temporary token to decrypt the image. The tokencan be valid for a limited time, and by providing the token back to theencryption service, the decrypted image (or fingerprint, eye pattern,etc.) is provided to the software (or to the verification agentcomputing device). The software then provides or otherwise makesavailable the decrypted image to the verification agent.

Second stage authentication data (e.g., a second code such as a 6-digitcode) is generated and transmitted in process block 512. In someexamples, the second stage authentication data is transmitted atsubstantially the same time as the identity information is transmitted.In some examples, the second stage authentication data is transmittedafter a match is confirmed between biometric information and the personin the presence of the verification agent. The blockchain-based identityand transaction platform account of the recipient can include anassociated phone number or other information identifying a mobile devicesuch as a smart phone, feature phone, or tablet. In some examples, thesecond stage authentication data is sent to the mobile device associatedwith the recipient, and if the person in the presence of theverification agent is in possession of the associated mobile device,then the person can provide the second code to the verification agent.In some examples, the second stage authentication data is sent in asimilar manner to the first stage authentication data (e.g., via emailmessage, application alert, or text message).

In process block 514, an indication is received that the second stageauthentication data has been provided to the verification agent. Thesecond stage authentication data and the code provided to theverification agent can then be compared to verify that the code providedto the verification agent is correct. After verifying the second stageauthentication data, it is determined in process block 516 that theperson in the presence of the verification agent is the actualrecipient, and the transaction is authorized. In the refugee example,authorization can include the food packet being given to the refugee. Infunds transfer examples, authorization can include physically handingmoney to the person or initiating/completing a transfer betweenaccounts. In some examples, the blockchain-based identity andtransaction platform can hold funds as an intermediary and disburse themto a linked account when the transaction is authorized. In otherexamples, the platform does not actually access or have control over thefunds.

The multi-stage verification provides several layers of security andrequires that a person attempting to claim a benefit must have the firststage authentication data (e.g., first code) associated with the benefitas well as the second stage authentication data (e.g., second code) sentafter verification of the first code. Further, in some examples, theagent explicitly confirms that the person has a physical appearance orother characteristic corresponding to the actual recipient or implicitlyconfirms an identity match by entering the second code. Further securitycan be implemented by requiring that the person in the agent's presencebe in physical possession of the intended recipient's mobile device. Insome examples, one or more of these security layers may be omitted. Inone particular example, fewer layers of security are used for lowervalue transactions (e.g., funds transfers under $100), and additionallayers of security are provided for higher value transactions.Additional layers of security beyond those discussed with respect toFIG. 5 are also possible.

In some examples, process block 510 is omitted (and an image orbiometric data of the intended recipient is not transmitted), and afterthe first stage authentication data is verified, second stageauthentication data is generated and transmitted to the recipient'saccount and/or mobile device.

Method 500 can also include storing a record of the transaction (e.g.,including particular transaction components, location data, technicaldevice/network details, etc.) in the blockchain in association with therecipient and/or sender. In some examples, only authorized and completedtransactions are stored. The information stored can include therecipient, the sender, and characteristics of the transaction (e.g.,funds transfer, aid assistance, etc.). The first and second stageauthentication data can be associated with both the recipient and thetransaction.

FIG. 6 is an interaction diagram 600 illustrating a transactionverification process such as that described with respect to FIG. 5. FIG.6 is discussed with reference to a specific example in which thetransaction is a funds transfer, the first stage authentication data isa first code, the identity information is an image, and the second stageauthentication data is a second code. A similar set of interactionsapplies to other scenarios, such as authorization of food or medicalassistance.

A sender initiates a funds transfer to a recipient who has an accountwith the blockchain-based identity and transaction platform. Therecipient has a trust relationship with the sender. In interaction 602,the details of the initiated transaction, including the recipient, typeof transaction (funds transfer), and amount to transfer are submitted bythe sender to a server(s) computer implementing aspects of theblockchain-based identity and transaction platform, such as servercomputer(s) 106 of FIG. 1. In interaction 604, first stageauthentication data (a first code) is sent to the recipient's account.The first code can be sent, for example, as a text message or email. Thefirst code can also be sent as an account alert that appears in a webinterface (or in client-side software running on a computing device ormobile device). The message can also provide instructions to therecipient for completing the transaction to claim the funds.

The recipient then provides the first code to a verification agent ininteraction 606. In some examples, the code can be shown to a personserving as an agent, who then enters the code into a verification agentcomputing device. In other examples, the recipient can enter the codeinto an automated terminal or kiosk. In still other examples, theverification agent computing device can be remote, and the recipienteither forwards the message to the verification agent or enters the codevia a web interface.

The verification agent enters and sends the code provided by therecipient back to the server(s) in interaction 608. The server(s) verifythat the code matches the first code sent in interaction 604. In someexamples, if there is not a match, the transaction is cancelled. Inother examples, a limited number of code entry attempts are permittedbefore the transaction is cancelled.

After determining that the first code matches, identity information(e.g. an image of the intended recipient) is used to further confirmthat the person who provided the first code is the intended recipient.In interaction 610, the server(s) send the recipient's unique identifier(e.g., the public key corresponding to the recipient's encrypted imageor other identity information) to the blockchain to retrieve therecipient's encrypted image. In transaction 612, the encrypted image isprovided to the server(s). In examples in which encryption is handled bythe server(s), the image is then decrypted. In examples in which anencryption service is used, such as FIG. 6, the server(s) interact withthe encryption service to decrypt the image. In FIG. 6, this is donethrough use of a decryption token. The server(s) send a token request tothe encryption service in interaction 614, and a decryption token isprovided back to the server(s) in interaction 616. The decryption tokenallows the server(s) to decrypt the image and provide the decryptedimage to the verification agent in interaction 618. In some examples,the decrypted image can be sent directly from the encryption service tothe verification agent. In certain instances when other forms ofbiometrics (such as fingerprints, iris patterns, or facial recognition)are used, the decryption steps can include matching a physicallypresented fingerprint, iris, or face to stored biometric data (e.g.,biometric data encrypted and stored on the blockchain).

In examples in which the verification agent is a person interacting witha verification agent computing device, the decrypted image of theintended recipient can be presented on the verification agent computingdevice, and the agent can make a judgment as to whether the person inthe agent's presence appears to be the same as the person pictured inthe image. In examples in which the verification agent is an automatedterminal, the person can present their face to allow the terminal tocreate an image and then compare that image to the decrypted image ofthe intended recipient using facial recognition or other imagerecognition software. In examples in which the verification agent isremote (whether a remote person or a remote computing device), theperson can be instructed to take a selfie and send the selfie to averification agent/upload the selfie. The selfie and the decrypted imagecan then be compared either by the remote person or by softwareexecuting on the remote computing device. In interaction 620, anidentity match confirmation is provided back to the server(s) by theverification agent computing device indicating that the person appearsto be the intended recipient.

At this point, both the first code and an image of the intendedrecipient have been used to verify that the person attempting to claimthe funds is the intended recipient. It is possible that a person who isnot the intended recipient could have intercepted the first code (e.g.,by accessing the initial message while using the intended recipient'sphone), and it is further possible that the person intercepting thefirst code resembles the intended recipient sufficiently to convince averification agent (or facial recognition software). Although suchsituations would likely be rare, an additional layer of security canalso be used—sending a second code to the recipient.

In interaction 622, the server(s) send second stage authentication data(e.g., a second code), which can be time-limited, to the recipient'saccount (e.g., via text message, email message, or application alert).The recipient then provides the second code back to the verificationagent in interaction 624. The verification agent sends the providedsecond code back to the server(s) in interaction 626, and if the codematches the second code sent to the recipient's account in interaction622, then the transaction is authorized. In examples in which the secondcode is time-limited, the transaction is only authorized if executedwithin predetermined time constraints. The funds transfer can then becompleted or authorized. In examples in which the benefit is a physicalitem or service such as a food packet or medical aid (e.g., a vaccine,medication, supplement, procedure, etc.), then the server(s) communicateto the verification agent that release of the item/service isauthorized. In a refugee context, for example, a food packet can then behanded or automatically dispensed to the recipient. The completedtransaction is then stored in the blockchain in association with therecipient and/or the sender.

In some examples, interaction 620, in which the identity matchconfirmation is provided back to the server(s), is not performedaffirmatively, but a match is implicitly confirmed when the verificationagent enters the second code in interaction 626. In such examples, afterthe verification agent has provided the first code to the server(s) ininteraction 608, and the first code has been verified by the server(s)(and after the retrieval/decryption interactions 610, 612, 614, and 616,if performed) the second code is sent to the recipient account ininteraction 622 at substantially the same time as the decrypted image issent to the verification agent in interaction 618. When the person inthe verification agent's presence provides the second code to the agentin interaction 624, the agent can refuse to enter the second code (orcancel the transaction) if the person in the agent's presence does notappear to match the decrypted image. Such an example is illustrated inFIG. 7.

In various examples, the verification agent can be implemented on theserver(s) or eliminated. For example: the first code provided ininteraction 604 can be provided directly back to the server(s); thedecrypted image can be retained at the server(s) and not be sent to theverification agent and instead a person can provide a selfie which iscompared to the decrypted image at the server(s); and the second codereceived at the recipient's mobile device can be provided directly backto the server(s) (e.g., by entering/uploading the code through aninterface on the mobile device).

FIG. 7 is an interaction diagram 700 illustrating a transactionverification process such as that described with respect to FIGS. 5 and6. In FIG. 7, the transaction is a funds transfer, the first stageauthentication data is a 9-digit code, the identity information is animage, and the second stage authentication data is a 6-digit code. Aswith FIG. 6, a similar set of interactions can apply to other scenarios,such as authorization of food or medical assistance.

A sender initiates a funds transfer to a recipient who has an accountwith the blockchain-based identity and transaction platform. Therecipient has a trust relationship with the sender. In interaction 702,the details of the initiated transaction, including the recipient, typeof transaction (funds transfer), and amount to transfer are submitted bythe sender to a server(s) computer implementing aspects of theblockchain-based identity and transaction platform, such as servercomputer(s) 106 of FIG. 1. In interaction 704, first stageauthentication data (a 9-digit code) is sent to the recipient's account.The 9-digit code can be sent, for example, as a text message or email.The code can also be sent as an account alert that appears in a webinterface (or client-side software running on a computing device ormobile device). The message can also provide instructions to therecipient for completing the transaction to claim the funds.

The recipient then provides the 9-digit code to a verification agent ininteraction 706. In some examples, the code can be shown to a personserving as an agent, who then enters the code into a verification agentcomputing device. In other examples, the recipient can enter the codeinto an automated terminal or kiosk. In still other examples, theverification agent computing device can be remote, and the recipienteither forwards the message to the verification agent or enters the codevia a web interface.

The verification agent enters and sends the 9-digit code provided by therecipient back to the server(s) in interaction 708. The server(s) verifythat the code matches the code sent in interaction 704. In someexamples, if the code does not match, the transaction is cancelled. Inother examples, a limited number of code entry attempts are permittedbefore the transaction is cancelled.

After determining that the 9-digit code matches, identity information(e.g. an image of the intended recipient) is used to further confirmthat the person who provided the 9-digit code is the intended recipient.In interaction 710, the server(s) send the recipient's unique identifier(e.g., the public key corresponding to the recipient's encrypted imageor other identity information) to the blockchain to retrieve therecipient's encrypted image. In transaction 712, the encrypted image isprovided to the server(s). In examples in which encryption is handled bythe server(s), the image is then decrypted. In examples in which anencryption service is used, such as FIGS. 6 and 7, the server(s)interact with the encryption service to decrypt the image. In FIG. 7,this is done through use of a decryption token. The server(s) send atoken request to the encryption service in interaction 714, and adecryption token is provided back to the server(s) in interaction 716.The decryption token allows the server(s) to decrypt the image andprovide the decrypted image to the verification agent in interaction718.

In interaction 720, the server(s) send second stage authentication data(e.g., a 6-digit code), which can be time-limited, to the recipient'smobile device (or in some examples, to the user's account). Interaction720 can occur substantially at the same time as the decrypted image istransmitted to the verification agent in interaction 718. The recipientthen provides the 6-digit code back to the verification agent ininteraction 722. If the decrypted image provided to the agent ininteraction 718 does not appear to match the person in the agent'spresence, the verification agent can refuse to enter the 6-digit code orotherwise cancel the transaction. This serves as an extra layer ofsecurity to ensure that the person attempting to claim a benefit is theintended recipient. If the decrypted image does match the person in theagent's presence, then the verification agent sends the provided 6-digitcode back to the server(s) in interaction 724, and if the code matchesthe 6-digit code sent to the recipient's mobile device in interaction720, then the transaction is authorized.

In examples in which the 6-digit code is time-limited, the transactionis only authorized if executed within predetermined time constraints.The funds transfer can then be completed or authorized. In examples inwhich the benefit is a physical item or service such as a food packet ormedical aid (e.g., a vaccine, medication, supplement, procedure, etc.),then the server(s) communicate to the verification agent that release ofthe item/service is authorized. In a refugee context, for example, afood packet can then be handed or automatically dispensed to therecipient. The completed transaction is then stored in the blockchain inassociation with the recipient and/or the sender.

FIG. 8 illustrates a user interface 800 that provides a number ofdifferent options to sign in to a blockchain-based identity andtransaction platform, including option 802 to sign in using a Facebookaccount, option 804 to sign in using a Twitter account, option 806 tosign in using a Google account, and option 808 to sign in using a phonenumber or email address. User interface 800, as well as the userinterfaces discussed with reference to FIGS. 9-23, can be presented in aweb application or client-side software executing on a client computingdevice.

In FIG. 9, user interface 900 displays an email sign in user interface.FIG. 10 illustrates a user interface 1000 in which the user has signedin. User interface 1000 includes a “Transfers” tab 1002, a “Connections”tab 1004, and a user tab 1006 (user “Ashish Gadnis” shown). Transferstab 1002 can display all or recent transfers to or from the signed-inuser made through the blockchain-based identity and transactionplatform. Connections tab 1004, the active tab in user interface 1000,shows connections with whom the user has established a trustrelationship.

FIG. 11 shows a user interface 1100 in which a user tab 1102, which canbe similar to user tab 1006, is active. User interface 1100 displaysprofile information for the user, including the user's platform profile1104, which can include login/password information, birth date,text-capable mobile phone number, email address, physical address, orother information. The profile information can also include passportinformation 1106, driver license information 1108, U.S. social securityinformation 1110, and non-U.S. identity information 1112. Profileinformation can also include additional information such as visa orother status information. Some or all of the profile information canalso be part of the user's economic identity.

FIG. 12 illustrates a user interface 1200 through which a user caninvite another person to either form a trust relationship or toestablish an account as a user of the platform and form a trustrelationship. User interface 1200 is presented while a connections tab1202 is active. Invitation information 1204 can include the invitee'sname, email address, text-capable mobile phone number, country, address,and/or other information. Once invitation information 1204 is entered, amessage can be sent to the invitee, and the invitee can be prompted toestablish an account and/or establish a trust relationship with theuser.

FIG. 13 illustrates a user interface 1300 showing a number of previoustransactions 1302 displayed under a “My Transfers” heading. Previoustransactions 1302 include funds transfers both to and from the user. Insome examples, the user is able to filter the types of transactionsdisplayed (e.g., show only funds transfers, show food and medicalassistance authorization, etc.). FIG. 14 shows a user interface 1400 inwhich a detailed transaction view is displayed. Transaction 1402includes a message “Health,” as well as first authentication data“Secret Key Code: B33-99C-861,” and instructions to provide the code tothe local agent to receive the transfer. Transaction 1404 includessimilarly includes a message, code, and instructions.

FIG. 15 illustrates a user interface 1500 in which a platformadministrator is logged in, as indicated by the “BanQu Administrator”tab 1502. The administrator can view additional information and performadditional actions. For example, “Agent” tab 1504 allows theadministrator to act as an agent, and “Blockchain” tab 1506 allows theadministrator to access a blockchain view of a transaction, asillustrated in FIG. 20.

In user interface 1600 of FIG. 16, agent tab 1602 is active, and atransfer lookup interface 1604 is presented. Transfers can be looked upby a key code (e.g., a 9-digit code) and/or additional information suchas recipient name, email address, or phone number. User interface 1600can be, for example, the interface through which an agent enters firstauthentication data (such as a 9-digit code). In user interface 1700 ofFIG. 17, a key code has been entered, and a transfer found interface1702 is presented that includes identity information 1704 for therecipient (an image) along with the “PhotoETag” 1706, which is a privatekey, enabled for one-time usage, that verifies the photo and thereceiver's identity. In some examples, transfer lookup interface 1604 iswhat a verification agent can use during a transaction verificationprocess as discussed, for example, with respect to FIGS. 5, 6, and 7.

FIG. 18 illustrates a user interface 1800 similar to user interface 1700of FIG. 17, but additional information is present (indicating a laterstage in verification), including second-stage authentication data 1802,shown as a 6-digit code, that has been sent to a recipient's mobiledevice or account and presented to and entered by a verification agent.In some examples, user interface 1700 of FIG. 17 and user interface 1800of FIG. 18 are what an agent sees after the first-stage authenticationdata is determined to be a match (FIG. 17) and after second stageauthentication data has been entered by the agent (FIG. 18). The image(identity information 1704) shown in transfer found user interface 1702can be the decrypted identity information provided to the agent. Forexample, a verification agent who has entered a 9-digit code ispresented with the image of the intended recipient and can (in someexamples) confirm that a person in the agent's presence appears to matchthe image. Confirmation can either be an explicit step, or confirmationcan be implicit if the agent enters a second code (or other second stageauthentication data that was generated after verification of the firststage authentication data) provided by the person in the agent'spresence.

In some examples, after transfer found user interface 1702 is displayed,the agent confirms that the displayed image resembles a person in theagent's presence, and then second-stage authentication data 1802 isgenerated and sent to the recipient's mobile device and is displayed inuser interface 1800. In some examples, confirmation of the person'sidentity is either not performed or is implicit in the verificationagent entering a second code. In some examples, second-stageauthentication data 1802 is shown in user interface 1800 at the timesecond-stage authentication data 1802 is sent to the mobile device ofthe recipient, and the agent can verify whether or not the person in theagent's presence has provided the correct code. In other examples, theagent is not provided the code, and the agent simply enters what theperson in the agent's presence provides, and verification of the code isdetermined by the platform.

Once the recipient receives the second-stage authentication data 1802and provides this code to the agent, the agent can either authorize thetransaction if there is a match or enter the provided code, and if amatch is determined, the agent is notified that the transaction isauthorized and/or has been completed, as is shown in transfer completeuser interface 1902 of user interface 1900 of FIG. 19.

In user interface 2000 of FIG. 20, blockchain tab 2002 is active. Userinterface 2000 includes a dashboard view that includes a current blocknumber 2004 in the blockchain where the completed transaction is stored.The dashboard view also includes a browser session information 2006 thatindicates how many browsers are currently directly accessing theblockchain at the current point in time and blockchain peer information2008 that indicates how many blockchain nodes are being accessed inorder to display the platform blockchain transactions. Pending view 2010illustrates the data stored in the current block, including thetransaction.

FIG. 21 shows a user interface 2100 in which a pending view 2102includes a transaction-by-transaction breakdown of what is stored in thecurrent block. Encrypted and hashed data are stored on the blockchain.Each transaction, and the different information describing thetransaction, becomes part of the immutable blocks that are stored on thepermissioned blockchain (for example, an Ethereum blockchain). Thestored information representing , including the first stageauthentication data (“token”), amount transferred (“amount”), as well assender, receiver, and agent information.

FIG. 22 illustrates a user interface 2200 of an email program in which amessage 2202 is sent to the recipient indicating that first-stageauthentication data has been provided and including a “Cash Outconfirmation Code” (second-stage authentication data) that is to beprovided to the verification agent to complete the transaction. In someexamples, the second-stage authentication data is sent to a mobiledevice associated with the recipient, and in other examples, such asthat shown in FIG. 22, the second-stage authentication data is sent viaemail, or message alert sent through a software application associatedwith the platform.

FIG. 23 illustrates a user interface 2300 illustrating a transfercomplete email confirmation 2302 provided to the sender after successfulcompletion of a transfer.

The information associated with a user can be stored in differentblocks, either pre-defined by the application or created ad-hoc by theuser, in the blockchain. To retrieve this information, for example whena user logs in to a web application and the user's profile is presented,a “projection” can be created by searching the blockchain forinformation associated with the user and retrieving that information.For example, a search based on the user's unique identifier can beperformed.

Projections can be created for all information associated with a user'saccount and/or for different “personas.” A user can establish differentpersonas within the user's account that can each include different typesand amounts of information. For example, a user can create a “health”persona that includes identity information and health information(vaccine records, medical records, etc.) but not employment information,education information, etc. that is unrelated to the user's health.Similarly, a user can create an education persona that includes identityand education information but not health, property ownershipinformation, etc. that is unrelated to the user's education.

The user can also establish different logins/login approaches to accessthe different personas. In some examples, logins of varying levels ofsecurity are available, and more secure login approaches (e.g.,multi-factor authentication, thumb/fingerprints, etc.) can be used forinformation the user considers to be more sensitive or confidential, andless secure login approaches (e.g., pin, password, passphrase, etc.) canbe used for information the user considers less sensitive orconfidential. In some examples, a same login is used for some or allpersonas. Logins can be used, for example, when a user wishes to share aparticular persona with another user or entity.

Example personas are illustrated in FIG. 27. A secured, blockchain-basedeconomic identity 2702 (which can be similar to economic identity 200 ofFIG. 2, for example) is stored on one or more blocks in a blockchain.Different personas include or access different aspects of economicidentity 2702. For example, a health persona 2704, accessible by athumbprint login 2706, can include a user's medical records orvaccination history and allows a user to visit a medical clinic ormedical aid station that has an account in the blockchain-based identityand transaction platform, enter contact information and/or a username,and provide a thumbprint to allow the medical clinic to have access tothe user's health records and other information included in healthpersona 2704. A medical clinic can also have a pre-defined personaestablished which can access the user's information (with the user'spermission).

Education persona 2708 can include grade reports, transcripts, or otherinformation and can be accessible, for example, via passphrase 2710.Utility persona 2712 can include various utility records, includingservice addresses, payments, usage history, etc. and can be accessed byPIN code 2714. A general or default persona can also be created. Thepersona approach allows a user to control what information the user isreleasing to various institutions and other users and to maintain otherdata as private. Although particular access methods (thumbprint 2706,passphrase 2710, and PIN code 2714) are shown in FIG. 27 as associatedwith particular personas, various different access methods can beselected or assigned to any persona.

The secure storage capabilities of the blockchain have been discussedherein, but the blockchain can also be capable of executing code, whichcan be implemented as “smart contracts,” which are programs that arestored on the blockchain and executed on the blockchain.

Example Computing Systems

FIG. 24 depicts a generalized example of a suitable computing system2400 in which the described innovations may be implemented. Thecomputing system 2400 is not intended to suggest any limitation as toscope of use or functionality, as the innovations may be implemented indiverse general-purpose or special-purpose computing systems.

With reference to FIG. 24, the computing system 2400 includes one ormore processing units 2410, 2415 and memory 2420, 2425. In FIG. 24, thisbasic configuration 2430 is included within a dashed line. Theprocessing units 2410, 2415 execute computer-executable instructions. Aprocessing unit can be a general-purpose central processing unit (CPU),processor in an application-specific integrated circuit (ASIC), or anyother type of processor. In a multi-processing system, multipleprocessing units execute computer-executable instructions to increaseprocessing power. For example, FIG. 24 shows a central processing unit2410 as well as a graphics processing unit or co-processing unit 2415.The tangible memory 2420, 2425 may be volatile memory (e.g., registers,cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory,etc.), or some combination of the two, accessible by the processingunit(s). The memory 2420, 2425 stores software 2480 implementing one ormore innovations described herein, in the form of computer-executableinstructions suitable for execution by the processing unit(s). Forexample, memory 2420 can store software 2480 implementing enrollmentengine 116 and transaction engine 118 of FIG. 1.

A computing system may have additional features. For example, thecomputing system 2400 includes storage 2440, one or more input devices2450, one or more output devices 2460, and one or more communicationconnections 2470. An interconnection mechanism (not shown) such as abus, controller, or network interconnects the components of thecomputing system 2400. Typically, operating system software (not shown)provides an operating environment for other software executing in thecomputing system 2400, and coordinates activities of the components ofthe computing system 2400.

The tangible storage 2440 may be removable or non-removable, andincludes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, orany other medium which can be used to store information and which can beaccessed within the computing system 2400. The storage 2440 storesinstructions for the software 2480 implementing one or more innovationsdescribed herein.

The input device(s) 2450 may be a touch input device such as a keyboard,mouse, pen, or trackball, a voice input device, a scanning device, oranother device that provides input to the computing system 2400. Forvideo encoding, the input device(s) 2450 may be a camera, video card, TVtuner card, or similar device that accepts video input in analog ordigital form, or a CD-ROM or CD-RW that reads video samples into thecomputing system 2400. The output device(s) 2460 may be a display,printer, speaker, CD-writer, or another device that provides output fromthe computing system 2400.

The communication connection(s) 2470 enable communication over acommunication medium to another computing entity. The communicationmedium conveys information such as computer-executable instructions,audio or video input or output, or other data in a modulated datasignal. A modulated data signal is a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia can use an electrical, optical, RF, or other carrier.

The innovations can be described in the general context ofcomputer-executable instructions, such as those included in programmodules, being executed in a computing system on a target real orvirtual processor. Generally, program modules include routines,programs, libraries, objects, classes, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The functionality of the program modules may be combined or splitbetween program modules as desired in various embodiments.Computer-executable instructions for program modules may be executedwithin a local or distributed computing system.

The terms “system” and “device” are used interchangeably herein. Unlessthe context clearly indicates otherwise, neither term implies anylimitation on a type of computing system or computing device. Ingeneral, a computing system or computing device can be local ordistributed, and can include any combination of special-purpose hardwareand/or general-purpose hardware with software implementing thefunctionality described herein.

For the sake of presentation, the detailed description uses terms like“determine” and “use” to describe computer operations in a computingsystem. These terms are high-level abstractions for operations performedby a computer, and should not be confused with acts performed by a humanbeing. The actual computer operations corresponding to these terms varydepending on implementation.

Example Mobile Devices

FIG. 25 is a system diagram depicting an example mobile device 2500including a variety of optional hardware and software components, showngenerally at 2502. Any components 2502 in the mobile device cancommunicate with any other component, although not all connections areshown, for ease of illustration. The mobile device can be any of avariety of computing devices (e.g., cell phone, smartphone, handheldcomputer, Personal Digital Assistant (PDA), etc.) and can allow wirelesstwo-way communications with one or more mobile communications networks2504, such as a cellular, satellite, or other network.

The illustrated mobile device 2500 can include a controller or processor2510 (e.g., signal processor, microprocessor, ASIC, or other control andprocessing logic circuitry) for performing such tasks as signal coding,data processing, input/output processing, power control, and/or otherfunctions. An operating system 2512 can control the allocation and usageof the components 2502 and support for one or more application programs2514. The application programs can include common mobile computingapplications (e.g., email applications, calendars, contact managers, webbrowsers, messaging applications), or any other computing application.Functionality 2513 for accessing an application store can also be usedfor acquiring and updating application programs 2514.

The illustrated mobile device 200 can include memory 2520. Memory 2520can include non-removable memory 2522 and/or removable memory 2524. Thenon-removable memory 2522 can include RAM, ROM, flash memory, a harddisk, or other well-known memory storage technologies. The removablememory 2524 can include flash memory or a Subscriber Identity Module(SIM) card, which is well known in GSM communication systems, or otherwell-known memory storage technologies, such as “smart cards.” Thememory 2520 can be used for storing data and/or code for running theoperating system 2512 and the applications 2514. Example data caninclude web pages, text, images, sound files, video data, or other datasets to be sent to and/or received from one or more network servers orother devices via one or more wired or wireless networks. The memory2520 can be used to store a subscriber identifier, such as anInternational Mobile Subscriber Identity (IMSI), and an equipmentidentifier, such as an International Mobile Equipment Identifier (IMEI).Such identifiers can be transmitted to a network server to identifyusers and equipment. The memory 2520 can store instructions or codeimplementing enrollment engine 116 and transaction engine 118 of FIG. 1.

The mobile device 2500 can support one or more input devices 2530, suchas a touchscreen 2532, microphone 2534, camera 2536, physical keyboard2538 and/or trackball 2540 and one or more output devices 2550, such asa speaker 2552 and a display 2554. Other possible output devices (notshown) can include piezoelectric or other haptic output devices. Somedevices can serve more than one input/output function. For example,touchscreen 2532 and display 2554 can be combined in a singleinput/output device.

The input devices 2530 can include a Natural User Interface (NUI). AnNUI is any interface technology that enables a user to interact with adevice in a “natural” manner, free from artificial constraints imposedby input devices such as mice, keyboards, remote controls, and the like.Examples of NUI methods include those relying on speech recognition,touch and stylus recognition, gesture recognition both on screen andadjacent to the screen, air gestures, head and eye tracking, voice andspeech, vision, touch, gestures, and machine intelligence. Otherexamples of a NUI include motion gesture detection usingaccelerometers/gyroscopes, facial recognition, 3D displays, head, eye ,and gaze tracking, immersive augmented reality and virtual realitysystems, all of which provide a more natural interface, as well astechnologies for sensing brain activity using electric field sensingelectrodes (EEG and related methods). Thus, in one specific example, theoperating system 2512 or applications 2514 can comprisespeech-recognition software as part of a voice user interface thatallows a user to operate the device 2500 via voice commands Further, thedevice 2500 can comprise input devices and software that allows for userinteraction via a user's spatial gestures, such as detecting andinterpreting gestures to provide input to a gaming application.

A wireless modem 2560 can be coupled to an antenna (not shown) and cansupport two-way communications between the processor 2510 and externaldevices, as is well understood in the art. The modem 2560 is showngenerically and can include a cellular modem for communicating with themobile communication network 2504 and/or other radio-based modems (e.g.,Bluetooth 2564 or Wi-Fi 2562). The wireless modem 2560 is typicallyconfigured for communication with one or more cellular networks, such asa GSM network for data and voice communications within a single cellularnetwork, between cellular networks, or between the mobile device and apublic switched telephone network (PSTN).

The mobile device can further include at least one input/output port2580, a power supply 2582, a satellite navigation system receiver 2584,such as a Global Positioning System (GPS) receiver, an accelerometer2586, and/or a physical connector 2590, which can be a USB port, IEEE1394 (FireWire) port, and/or RS-232 port. The illustrated components2502 are not required or all-inclusive, as any components can be deletedand other components can be added.

Example Cloud-Supported Environments

FIG. 26 illustrates a generalized example of a suitable cloud-supportedenvironment 2600 in which described embodiments, techniques, andtechnologies may be implemented. In the example environment 2600,various types of services (e.g., computing services) are provided by acloud 2610. For example, the cloud 2610 can comprise a collection ofcomputing devices, which may be located centrally or distributed, thatprovide cloud-based services to various types of users and devicesconnected via a network such as the Internet. The implementationenvironment 2600 can be used in different ways to accomplish computingtasks. For example, some tasks (e.g., processing user input andpresenting a user interface) can be performed on local computing devices(e.g., connected devices 2630, 2640, 2650) while other tasks (e.g.,storage of data to be used in subsequent processing) can be performed inthe cloud 2610.

In example environment 2600, the cloud 2610 provides services forconnected devices 2630, 2640, 2650 with a variety of screencapabilities. Connected device 2630 represents a device with a computerscreen 2635 (e.g., a mid-size screen). For example, connected device2630 could be a personal computer such as desktop computer, laptop,notebook, netbook, or the like. Connected device 2640 represents adevice with a mobile device screen 2645 (e.g., a small size screen). Forexample, connected device 2640 could be a mobile phone, smart phone,personal digital assistant, tablet computer, and the like. Connecteddevice 2650 represents a device with a large screen 2655. For example,connected device 2650 could be a television screen (e.g., a smarttelevision) or another device connected to a television (e.g., a set-topbox or gaming console) or the like. One or more of the connected devices2630, 2640, 2650 can include touchscreen capabilities. Touchscreens canaccept input in different ways. For example, capacitive touchscreensdetect touch input when an object (e.g., a fingertip or stylus) distortsor interrupts an electrical current running across the surface. Asanother example, touchscreens can use optical sensors to detect touchinput when beams from the optical sensors are interrupted. Physicalcontact with the surface of the screen is not necessary for input to bedetected by some touchscreens. Devices without screen capabilities alsocan be used in example environment 2600. For example, the cloud 2610 canprovide services for one or more computers (e.g., server computers)without displays.

Services can be provided by the cloud 2610 through service providers2620, or through other providers of online services (not depicted). Forexample, cloud services can be customized to the screen size, displaycapability, and/or touchscreen capability of a particular connecteddevice (e.g., connected devices 2630, 2640, 2650).

In example environment 2600, the cloud 2610 provides the technologiesand solutions described herein to the various connected devices 2630,2640, 2650 using, at least in part, the service providers 2620. Forexample, the service providers 2620 can provide a centralized solutionfor various cloud-based services. The service providers 2620 can manageservice subscriptions for users and/or devices (e.g., for the connecteddevices 2630, 2640, 2650 and/or their respective users). Some or all ofthe functionality of enrollment engine 2660 and transaction engine 2662,which can be similar to enrollment engine 116 and transaction engine 118of FIG. 1, can be implemented in the cloud 2610.

Example Implementations

Although the operations of some of the disclosed methods are describedin a particular, sequential order for convenient presentation, it shouldbe understood that this manner of description encompasses rearrangement,unless a particular ordering is required by specific language set forthbelow. For example, operations described sequentially may in some casesbe rearranged or performed concurrently. Moreover, for the sake ofsimplicity, the attached figures may not show the various ways in whichthe disclosed methods can be used in conjunction with other methods.

Any of the disclosed methods can be implemented as computer-executableinstructions or a computer program product stored on one or morecomputer-readable storage media and executed on a computing device(e.g., any available computing device, including smart phones or othermobile devices that include computing hardware). Computer-readablestorage media are any available tangible media that can be accessedwithin a computing environment (e.g., one or more optical media discssuch as DVD or CD, volatile memory components (such as DRAM or SRAM), ornonvolatile memory components (such as flash memory or hard drives)). Byway of example and with reference to FIG. 24, computer-readable storagemedia include memory 2420 and 2425, and storage 2440. By way of exampleand with reference to FIG. 25, computer-readable storage media includememory and storage 2520, 2522, and 2524. The term computer-readablestorage media does not include signals and carrier waves. In addition,the term computer-readable storage media does not include communicationconnections (e.g., 2470, 2560, 2562, and 2564).

Any of the computer-executable instructions for implementing thedisclosed techniques as well as any data created and used duringimplementation of the disclosed embodiments can be stored on one or morecomputer-readable storage media. The computer-executable instructionscan be part of, for example, a dedicated software application or asoftware application that is accessed or downloaded via a web browser orother software application (such as a remote computing application).Such software can be executed, for example, on a single local computer(e.g., any suitable commercially available computer) or in a networkenvironment (e.g., via the Internet, a wide-area network, a local-areanetwork, a client-server network (such as a cloud computing network), orother such network) using one or more network computers.

For clarity, only certain selected aspects of the software-basedimplementations are described. Other details that are well known in theart are omitted. For example, it should be understood that the disclosedtechnology is not limited to any specific computer language or program.For instance, the disclosed technology can be implemented by softwarewritten in C++, Java, Perl, JavaScript, Adobe Flash, or any othersuitable programming language. Likewise, the disclosed technology is notlimited to any particular computer or type of hardware. Certain detailsof suitable computers and hardware are well known and need not be setforth in detail in this disclosure.

Furthermore, any of the software-based embodiments (comprising, forexample, computer-executable instructions for causing a computer toperform any of the disclosed methods) can be uploaded, downloaded, orremotely accessed through a suitable communication means. Such suitablecommunication means include, for example, the Internet, the World WideWeb, an intranet, software applications, cable (including fiber opticcable), magnetic communications, electromagnetic communications(including RF, microwave, and infrared communications), electroniccommunications, or other such communication means.

The disclosed methods, apparatus, and systems should not be construed aslimiting in any way. Instead, the present disclosure is directed towardall novel and nonobvious features and aspects of the various disclosedembodiments, alone and in various combinations and sub combinations withone another. The disclosed methods, apparatus, and systems are notlimited to any specific aspect or feature or combination thereof, nor dothe disclosed embodiments require that any one or more specificadvantages be present or problems be solved.

The technologies from any example can be combined with the technologiesdescribed in any one or more of the other examples. In view of the manypossible embodiments to which the principles of the disclosed technologymay be applied, it should be recognized that the illustrated embodimentsare examples of the disclosed technology and should not be taken as alimitation on the scope of the disclosed technology.

1. A computing device comprising one or more processors and one or morecomputer-readable storage media having stored thereincomputer-executable instructions for causing the one or more processors,when programmed thereby, to perform operations comprising: encryptingidentity information for a person and storing the encrypted identityinformation in a blockchain as part of enrolling the person as a user ina blockchain-based economic identity and transaction platform; storing,in the blockchain, records of trust relationships between the user andother users; and authorizing transactions between the user and one ormore of the other users with whom the user has formed a trustrelationship; and storing records of the transactions in the blockchain,wherein at least some of the transactions and identity informationcontribute to an economic identity of the user.
 2. The computing deviceof claim 1, wherein the operations further comprise providing theeconomic identity of the user to a requesting party, wherein therequesting party is another user in the blockchain-based economicidentity and transaction platform.
 3. The computing device of claim 1,wherein the economic identity further comprises at least one ofemployment history information, education history information, propertyownership information, or medical history information for the user, andwherein the at least one of employment history information, educationhistory information, property ownership information, or medical historyinformation is stored in the blockchain.
 4. The computing device ofclaim 1, wherein the identity information comprises an image of theperson, and wherein the identity information further comprises at leastone of a name, government identifier, fingerprint, or eye patterninformation.
 5. The computing device of claim 4, wherein the image ofthe person is used in authorizing the transactions.
 6. (canceled)
 7. Thecomputing device of claim 1, wherein the transactions comprise at leastone of a funds transfer, medical treatment authorization, or foodassistance authorization.
 8. A computer-implemented method comprising:receiving identity information for a person; encrypting the identityinformation; storing the encrypted identity information in a block of ablockchain; and establishing, based on the encrypted identityinformation, a unique identifier associated with the person.
 9. Themethod of claim 8, wherein the identity information comprises an imageof the person, and wherein the identity information further comprises atleast one of a name, government identifier, fingerprint or eye patterninformation.
 10. (canceled)
 11. The method of claim 8, whereinestablishing the unique identifier comprises designating the encryptedidentity information as the unique identifier.
 12. The method of claim8, further comprising associating, with the unique identifier, at leastone of medical, employment, educational, property ownership, or economicinformation corresponding to the person and storing the medical,employment, educational, property ownership, or economic information inthe blockchain.
 13. The method of claim 12, wherein at least one ofeconomic or employment information is stored in the blockchain inassociation with the unique identifier and represents an economicidentity of the person.
 14. The method of claim 8, further comprisingstoring, in association with the unique identifier and in theblockchain, transaction information representing one or moretransactions between the person and one or more additional parties. 15.The method of claim 8, further comprising storing, in association withthe unique identifier and in the blockchain, a record of a trustrelationship between the person and one or more additional parties. 16.One or more computer-readable memory or storage devices having storedthereon computer-executable instructions to cause a computer system,when programmed thereby, to perform operations comprising: identifying arecipient for a transaction; generating first stage authentication data;receiving an indication that the first stage authentication data hasbeen provided to a verification agent; verifying the first stageauthentication data; after verifying the first stage authenticationdata, retrieving identity information for the recipient from one or moreblocks in a blockchain and transmitting the identity information;generating and transmitting second stage authentication data; receivingan indication that the second stage authentication data has beenprovided to the verification agent; and after verifying the second stageauthentication data, determining that the person in the presence of theverification agent is the recipient and authorizing the transaction. 17.The one or more computer-readable memory or storage devices of claim 16,wherein the identity information comprises at least one of an image ofthe recipient, a fingerprint of the recipient, or eye patterninformation for the recipient.
 18. The one or more computer-readablememory or storage devices of claim 16, wherein the retrieved identityinformation is encrypted, and wherein the operations further comprise:requesting a decryption token; receiving a decryption token; anddecrypting the identity information for the recipient, wherein thetransmitted identity information is decrypted identity information. 19.The one or more computer-readable memory or storage devices of claim 16,wherein the operations further comprise storing a record of thetransaction in the blockchain in association with the recipient.
 20. Theone or more computer-readable memory or storage devices of claim 16,wherein the operations further comprise, prior to generating the firststage authentication data: establishing a record of a trust relationshipbetween the recipient and a sender; and storing the record of the trustrelationship in the blockchain.
 21. The one or more computer-readablememory or storage devices of claim 16, wherein the transaction is atleast one of a funds transfer, medical authorization, or food assistanceauthorization.
 22. The one or more computer-readable memory or storagedevices of claim 16, wherein the first and second stage authenticationdata are codes comprising at least one of numbers or letters.